An extensible markup language (XML) document management system refers to a system for accessing and managing an XML document stored in a server through a client. The system provides functions to create, retrieve, replace, and delete parts or all of the XML document.
As one of the XML document management system, there is an XML document management (XDM) system according to an open mobile alliance (OMA) standard.
The OMA XDM system includes an XDM client (XDMC), and XDM server (XDMS), and performs an XML document management by using an institution of electronics and telecommunication engineers (IETE) XML configuration access protocol (XCAP) (TETF RFC 4825).
The XCAP protocol is a protocol for enabling an operation with respect to a specific XML resource by using a hypertext transfer protocol/1.1 (HTTP/1.1). The XML resource includes an entire part of a specific XML document, a specific element of the XML document, or an attribute. And, the operation includes creation, retrieval, replacement, and deletion. That is, the XCAP protocol expresses a specific XML resource as an HTTP URI by using an XCAP uniform resource identifier (URI). And, the XCAP protocol requests retrieval, creation (change), and deletion with respect to the specific XML resource by using GET, PUT, DELETE methods of the HTTP/1.1.
The XCAP URI indicates an XML document stored in an XDM server, an element inside the XML document, or an attribute of the element. And, the XCAP URI may be expressed in the form of [XCAP RootURI]/[AUID]/users/[XUI].
The following table 1 explains the XCAP URI, and elements relating to the XCAP URI.
TABLE 1ElementsContentsXCAP URIAn HTTP URI including an XCAP root, a document selector, a node selector separator, and a node selector. As a result, the [XCAP Root URI] selects a specific XML node.XCAP RootA URI indicating an XCAP root. This does not URIcorrespond to a substantial resource of an XCAP server even if it is a grammatically effective URI. The substantial resource is created by adding additional path information to the XCAP Root URI.AUID(applicationA unique identifier inside a namespace of an unique ID)application unique ID created from an XCAP specification. This AUID identifies an XCAP resource accessed by one application, from an XCAP resource accessed by another application.XUI(XCAPCharacter rows. This is valid as a path factor of User Identifier)an HTTP URI. This XUI is associated with each user who receives a service from an XCAP server.XCAP rootA context including all of documents across all Application Usages and users that are managed by a server.DocumentA sequence of path segments separated from each selectorother by “/”. This identifies an XML document in a selected XCAP root.node selectorA single path segment consisting of two tilde separatorcharacters, “~~”. This is used to separate a document selector from a nodeselector in an HTTP URI.node selectorA sequence of path segments separated from each other by “/”. This is used to identify an XML node (element or attribute) selected in a document.
For instance, XCAP URI “http://xcap.example.com/address-book/users/sip:test@example.com/adbook1” indicates an “adbook1” document of a “test@example.com” user of an application recognized as an “address-book” of an “xcap.example.com” server.
When the “adbook1” document has contents shown in the following table 2, XCAP URI http://xcap.example.com/address-book/users/sip:test@example.com/addresses/address-book/entry/name” indicates an underlined <name> element of the following table 2.
TABLE 2<?xml version=“1.0” encoding=“UTF-8”?><address-book><entry><name>Jonathan Rosenberg</name><email>jdrosen@dynamicsoft.com</email><postal><street paved=“true”>600 Lanidex Pl</street><city>Parsippany</city><state>NJ</state><country>USA</country></postal><ietf-participant/></entry></address-book>
Hereinafter, examples of a main XCAP operation will be explained in more detail.
1. Element Retrieval
In order to retrieve the (first) “name” element in the table 2, a client sends an XCAP operation shown in the following table 3 to a server through an HTTP/1.1.
TABLE 3GET http://xcap.example.com/address-book/users/petri/adbook1/address-book/entry/name HTTP/1.1
Here, the server sends a response shown in the following table 4 through the HTTP/1.1.
TABLE 4<name>Jonathan Rosenberg</name>
2. Attribute Retrieval
In order to retrieve the “paved” attribute of the “name” element in the table 2, the client sends an XCAP operation shown in the following table 5 to the server.
TABLE 5GEThttp://xcap.example.com/address-book/users/petri/adbook1/address-book/entry/street/@paved HTTP/1.1
Here, the server sends a response shown in the following table 6.
Here, the server sends a response shown in the following table 6.
TABLE 6HTTP/1.1 200 OKContent-Type: application/xml-attribute-valueContent-Length: ...True
3. Element Deletion
In order to retrieve the “email” element of the “name” element in the table 2, the client sends an XCAP operation shown in the following table 7 to the server.
TABLE 7DELETEhttp://xcap.example.com/address-book/users/petri/adbook1/address-book/entry/name/email HTTP/1.1
Here, the server sends a response shown in the following table 8.
Here, the server sends a response shown in the following table 8.
TABLE 8HTTP/1.1 200 OK
As a result of the operation, the document of the table 2 is changed into that of the following table 9.
TABLE 9<?xml version=“1.0” encoding=“UTF-8”?><address-book><entry><name>Jonathan Rosenberg</name><postal><street paved=“true”>600 Lanidex Pl</street><city>Parsippany</city><state>NJ</state><country>USA</country></postal><ietf-participant/></entry></address-book>
4. Attribute Deletion
In order to delete the “paved” attribute of the “street” element in the table 2, the client sends an XCAP operation shown in the following table 10 to the server.
TABLE 10DELETEhttp://xcap.example.com/address-book/users/petri/adbook1/address-book/entry/name/postal/street/@paved HTTP/1.1
Here, the server sends a response shown in the following table 11.
TABLE 11HTTP/1.1 200 OK
As a result of the operation, the document of the table 2 is changed into that of the following table 12.
TABLE 12<?xml version=“1.0” encoding=“UTF-8”?><address-book><entry><name>Jonathan Rosenberg</name><postal><street>600 Lanidex Pl</street><city>Parsippany</city><state>NJ</state><country>USA</country></postal><ietf-participant/></entry></address-book>
5. Element Creation
In order to add the “phone” element to the (sub) element of the “entry” element in the table 2, the client sends an XCAP operation shown in the following table 13 to the server.
TABLE 13PUThttp://xcap.example.com/address-book/users/petri/adbook1/address-book/entry/phone HTTP/1.1Content-Type: application/xml-fragment-body<phone>+19739525000</phone>
Here, the server sends a response shown in the following table 14.
TABLE 14HTTP/1.1 200 OK
As a result of the operation, the document of the table 2 is changed into that of the following table 15.
TABLE 15<?xml version=“1.0” encoding=“UTF-8”?><address-book><entry><name>Jonathan Rosenberg</name><phone>+19739525000</phone><email>jdrosen@dynamicsoft.com</email><postal><street paved=“true”>600 Lanidex Pl</street><city>Parsippany</city><state>NJ</state><country>USA</country></postal><ietf-participant/></entry></address-book>
6. Element Replacement
In order to change the “name” element in the table 2, the client sends an XCAP operation shown in the following table 16 to the server.
TABLE 16PUThttp://xcap.example.com/address-book/users/petri/adbook1/address-book/entry/name HTTP/1.1Content-Type: application/xml-fragment-body<name>Jonathan D. Rosenberg</name>
Here, the server sends a response shown in the following table 17.
TABLE 17HTTP/1.1 200 OK
As a result of the operation, the document of the table 2 is changed into that of the following table 18.
TABLE 18<?xml version=“1.0” encoding=“UTF-8”?><address-book><entry><name>Jonathan D. Rosenberg</name><email>jdrosen@dynamicsoft.com</email><postal><street paved=“true”>600 Lanidex Pl</street><city>Parsippany</city><state>NJ</state><country>USA</country></postal><ietf-participant/></entry></address-book>
As shown in the tables 13 and 16, one XCAP syntax may be a creation operation or a replacement operation according to contents of an XML document, an object of an XCAP operation. That is, when an XCAP URI in the XCAP operation indicates a specific XML resource, if the specific XML resource already exists in the XML document, the XCAP operation serves as a replacement operation with respect to the specific XML resource. And, if the specific XML resource does not exists in the XML document, the XCAP operation serves as a creation operation with respect to the specific XML resource.
Next, will be explained restriction conditions that can be applied in case of changing document contents in the XML document management system.
In the XML document management system, when the client requests, from the server, changes of contents of the XML document through the XCAP operation, the server firstly checks whether the request satisfies predetermined restriction conditions. Then, the server performs the request only when the request satisfies the predetermined restriction conditions. The predetermined conditions include an XML schema, an element of a specific part, the number of attributes, uniqueness, etc.
The XML schema is description about an XML document type. Generally, the XML schema is expressed as restrictions of a structure and contents of the XML document, as well as basic syntactical restrictions applied by the XML itself. Accordingly, the restrictions by the XML schema correspond to one of the conditions.
The number of a specific element or attribute needs to be limited, and to satisfy uniqueness. For instance, a sub element of a ‘class’ element, ‘student’ has a condition that its number should not exceed 50 per one class. Under a state that 50 ‘student’ elements already exist, even if the client requests creation of one more ‘student’ element, the server does not perform the request because the request is not within the condition. As another example, a sub element of the ‘class’ element, ‘teacher’ has a condition that its number should be one per one class. Under a state that a ‘teacher’ elements already exist, even if the client requests creation of one more ‘teacher’ element, the server does not perform the request because the request is not within the condition.
Next, will be explained version management according to changes of document contents in the XML document management system.
Generally, when the client requests changes of an XML document through an XCAP from the server, the server checks whether a version of the client's XML document prior to the changes is consistent with a version of the server's corresponding XML document. When the two versions are consistent with each other as a result of the checks, the server performs the request.
For the checks, a header of an XCAP Response includes an Etag. The Etag is a version identifier with respect to a resource and provided by the server, and includes a kind of version number. The resource includes an XML document, and the Etag of the document is updated whenever contents of the document are changed.
Next, will be explained a method for requesting a plurality of operations at one time in the XML document management system.
Under an assumption that one request includes only a single operation, when a plurality operations are required to change many parts of a document, a plurality of requests including each operation have to be sequentially sent to the server and processed. In this case, a request according to IETF RFC 4825 is included.
An XML patch operation (IETF RFC 5261) is a standard with respect to an XML document type indicating contents for changing an XML document, an object of an XCAP operation. The XML patch operation document includes elements such as add, replace, remove, etc. The element indicates a method for changing another XML document. Since the XML patch operation document may include a plurality of elements, one XML patch operation document may include change contents corresponding to a plurality of XCAP operations. An example to express an XCAP operation by using an RFC 5261 standard includes a draft-ietf-simple-xcap-diff-09 standard.
The following table 19 explains terms relevant to the XML patch operation.
TABLE 19TermsContentsXCAP diff An XML document including a patch operationdocumentelement, a name space declaration, and anotherdocument content change required to change an XMLdocument, an object into a newly-patched XMLdocument XML.Patched An XML document obtained by applying one or moreXMLpatch operations defined in an XML diff document to andocumentXML document, an object.patch A single change, and a patch used to update an XMLoperationdocument, an object.patch An XML element indicating a single patch operation.operationelement
Example of XCAP Patch Operation
Hereinafter, an example of an XCAP patch operation will be explained. An XML document shown in the following table 20 corresponds to an object of an XCAP patch operation.
TABLE 20<?xml version=“1.0” encoding=“UTF-8”?><doc><note>This is a sample document</note></doc>
The XML patch operation can be implemented by using an XML diff document shown in the following table 21 with respect to the XML document of the table 20.
TABLE 21<?xml version=“1.0” encoding=“UTF-8”?><diff><add sel=“doc”><foo id=“ert4773”>This is a new child</foo></add></diff>
The XML diff document includes one patch operation element, “<add sel=“doc”><foo id=“ert4773”> This is a new child</foo></add>”. The patch operation element indicates searching for “doc” element in the XML document, and adding “<foo id=“ert4773”> This is a new child</foo>” to the searched element. That is, the “foo” element is added as a sub element of the “doc” element. The “foo” element has a value of “This is a new child”, and the “foo” element includes an “id” attribute having a value of “ert4773”.
As a result of the operation, the XML document of the table 20 is changed into that of the following table 22.
TABLE 22<?xml version=“1.0” encoding=“UTF-8”?><doc><note>This is a sample document</note><foo id=“ert4773”>This is a new child</foo></doc>
Next, the XML patch operation is implemented by using the XML diff document of the following table 23 with respect to the XML document of the table 22.
TABLE 23<?xml version=“1.0” encoding=“UTF-8”?><diff><add sel=“doc/foo[@id=‘ert4773’]” type=“@user”>Bob</add></diff>
The patch operation element of the table 23 indicates selecting one of sub elements of the “doc” element, “foo” elements in the XML document, the selected sub element having an attribute “id” of “ert4773”, and adding an attribute “user” having a value of “Bob” to the “foo” elements.
As a result of the operation, the XML document of the table 22 is changed into that of the following table 24.
TABLE 24<?xml version=“1.0” encoding=“UTF-8”?><doc><note>This is a sample document</note><foo id=“ert4773” user=“Bob”>This is a new child</foo></doc>
The two XML diff documents of the tables 21 and 23 may be integrated as a single XML diff document including a patch operation element of each document. The single XML diff document is shown in the following table 25.
TABLE 25<?xml version=“1.0” encoding=“UTF-8”?><diff><add sel=“doc”><foo id=“ert4773”>This is a new child</foo></add><add sel=“doc/foo[@id=‘ert4773’]” type=“@user”>Bob</add></diff>
That is, if the XML diff document of the table 25 is applied to the XML document of the table 20, the XML document of the table 20 is changed into the XML document of the table 24.
As aforementioned, one XML diff document may include therein a plurality of patch operation elements indicating an operation. Accordingly, in the XML document management system the client may request a plurality of operations through the XML diff document from the server.
Next, will be explained a change record function and a change cancel function in the XML document management system.
As aforementioned, a user of the XML document management system may change contents of the XML document stored in the server through the client.
A change record viewing function is a function for storing changed contents of the XML document according to time orders, and thereby reading partial or all changes of the XML document. A change cancel function is a function for cancelling the past change contents.
In order to support the change cancel function, the XML document management system requires the followings. First of all, the XML document management system has to store the past change contents. Especially, in case of change and deletion operations, the XML document management system has to store not only the past operations, but also a previous value of an XML resource, an object of the operations. Furthermore, the XML document management system has to also store a designator for designating an operation to be cancelled. The designator may include an identifier (ID) of an operation, a sequential number of an operation, an Etag value before or after each operation, a time when a corresponding operation has been executed, etc.
The change cancel function is implemented to cancel all operations executed from a specific time point of the past to the present. The function is implemented in the same manner as a function for retrieving a document of which change is to be cancelled, into a specific version of the past. An OMA XDM 2.1 version supports the change cancel function in the XML document management system.
Examples of Change Records in XML Document Management System
For the aforementioned change records, an XML history document may be used.
Hereinafter, examples of the XML history document will be explained. If an XCAP operation of the following table 27 is applied to an XML document of the following table 26, the document is changed into that of the table 28. Here, an XML history document including contents of the following table 29 is created as records of the operation.
TABLE 26<?xml version=“1.0” encoding=“UTF-8”?><doc><foo a=“1”>Sample text 1</foo><foo a=“2”>Sample text 2</foo></doc>
TABLE 27PUThttp://xcap.example.com/AUID/users/sip:userA@example.com/index/~~/example1/foo%5b@a=1%5d HTTP/1.1Content-Type:application/xml-fragment-body<foo a=“1”>This is A sample text 1</foo>
TABLE 28<?xml version=“1.0” encoding=“UTF-8”?><doc><foo a=“1”>This is a sample text 1</foo><foo a=“2”>Sample text 2</foo></doc>
TABLE 29<modify opid=“aaa111” type=“element” timestamp=“2009061815300001”sel=“doc/foo[@a=‘1’]”><requestor>sip:userA@example.com</requestor><timestamp>2009061815300001</timestamp><previous-etag>AABBCC</previous-etag><etag>DDEEFF</etag><previous-element><foo a=“1”>Sample text 1</foo></previous-element></operation>
Definitions of each XML element or attribute of the XML history document of the table 29 will be explained in the following table 30.
TABLE 30ModifyIndication that records are changed records.CreateIndication that records are created records.OpidIdentifier of an operation.TypeIndication to which an XML resource to be operated belongs. This may have a value of “element” or “attribute”, etc.TimestampTime when an operation has occurred.SelIndication a method for identifying an XML resource to be operated.RequestorSubject which has requested an operation.previous-Etag of an XML document to be operated etagbefore an operation.EtagEtag of an XML document to be operated after an operation.previous-Value of an XML resource to be operated elementbefore an operation.
Other examples of the XML history document will be explained. If an XCAP operation of the following table 31 is applied to an XML document of the following table 26, the document is changed into that of the table 32. Here, an XML history document including contents of the following table 33 is created as records of the operation.
TABLE 31PUThttp://xcap.example.com/AUID/users/sip:user@example.com/index/~~/example1/foo%5b@a=3%5d HTTP/1.1Content-Type:application/xml-fragment-body<foo a=“3”>Sample text 3</foo>
TABLE 32<create opid=“aaa113” type=“element” timestamp=“2009061815300001”sel=“doc/foo[@a=‘3’]”><requestor>sip:userA@example.com</requestor><timestamp>2009061815300001</timestamp><previous-etag>AABBCC</previous-etag><etag>DDEEFF</etag></operation>
TABLE 33<?xml version=“1.0” encoding=“UTF-8”?><doc><foo a=“1”>Sample text 1</foo><foo a=“2”>Sample text 2</foo><foo a=“3”>Sample text 3</foo></doc>
As another example of the change cancel function, only a specific operation of the past operations may be selectively cancelled. However, when performing this type of cancel function, the following problems may occur.
Operations applied to a specific document may have dependencies on each other. Accordingly, if a specific operation is cancelled, executions of other operations dependent on the specific operation may be influenced.
FIG. 1 shows a problem occurring when a specific operation is cancelled, due to dependencies of operations on each other. More concretely, FIG. 1 shows a problem that operations 4 and 6 can not be executed as an operation 2 is cancelled, in a state that the operations 4 and 6 are dependent on the operation 2.
For instance, the operation 2 may serve to create an element E, and to initialize a value of an attribute A of the element E into 100. The operation 4 serves to change a value of the attribute A into 200. And, the operation 6 serves to delete the element E. In this case, the operation 4 (change operation) and the operation 6 (deletion operation) are dependent on the operation 2 (creation operation). That is, if the operation 2 is cancelled, executions of the operations 4 and 6 are made to be impossible.
As another example, under an assumption that the element E has one instance, the operation 1 serves to create an instance E1 of the element E, the operation 2 serves to delete the instance E1, and the operation 4 serves to create another instance E2 of the element E. And, the operation 6 serves to delete the E2. In this case, if the operation 2 for deleting the E1 is cancelled, the operation 4 can not be executed due to a condition that the element E should have one instance. Furthermore, the operation 6 can not be executed because the E2 does not exist.